OIPA Release Notes 12.2.0.0

Oracle Insurance Policy Administration (OIPA) is a next-generation, flexible, rules-based insurance solution for life and annuities that supports policy processing across multiple lines of business. OIPA greatly enhances the ease of use and speed for business analysts, actuaries and others involved in the product configuration process. Robust navigation also makes it easy for users, including CSRs, to locate policy information and drill down into a granular level of customer detail. This allows insurers to respond more rapidly to customer inquiries, reduce call times and improve customer service. These release notes contain the enhancements made to Oracle Insurance Policy Administration release 12.2.0.0.

Configuration Updates for Upgrading to 12.2.0

Customers upgrading to 12.2.0 should review the following updates and apply the required configuration changes during upgrade.

  • CORS Configuration Updates - New CORS properties have been added for PAS, CYCLE, Admin Console, and Service Layer. Customers should use the latest property files from the 12.2.0 distribution and update the CORS origin settings based on their environment. The configured origin values should reflect trusted browser origins used to access the application.

  • Updated Keystore Requirement - A new keystore property has been introduced in 12.2.0 for PAS and CYCLE. Customers must replace the keystore file with the latest version included in the 12.2.0 distribution and ensure the required HMAC alias is present in the keystore configuration.

  • Native SSO Support - Native SSO is now available in 12.2.0 and can be enabled through the PAS configuration. Customers should refer to the product documentation for the required setup steps and supported configuration details.

  • Trust Store Passwords Moved to Environment Variables - The cycle.trustStorePassword, service.trustStorePassword, and outbound.trustStorePassword settings have been moved from the properties file to environment variables. Customers should configure these values in their environment and refer to the installation documentation for guidance.

Oracle Insurance Policy Administration

This section describes configuration, features and technology specific enhancements for GA release 12.2.0.0. OIPA now supports the following functionality:

Requirement History now Captured for all Rule-Based Additions and Updates

OIPA now captures history for requirements added or updated through attached business rules, including AddRequirements, ProcessRequirements, and CopyToRequirementFields, when processed via activities or requirements. Changes made to requirements are logged and visible in the new History tab on the client requirement screen. This ensures comprehensive traceability for all requirement operations, whether performed automatically or through the user interface. A new ClientRequirementHistory security page in Rules Palette allows administrators to manage access to requirement history information.

Enhanced Requirement Deletion Control

The DeleteRequirements business rule introduces enhanced control over requirement management during activity or requirement reversal and recycling processes. This rule can be attached to either an activity or a requirement, enabling organizations to define how direct child requirements should be handled when the parent activity or requirement is reversed.

With this feature, organizations can configure the system to:

  • Delete all direct child requirements,

  • Delete only selected direct child requirements, or

  • Apply specific business conditions to determine which requirements should be updated to the Deleted status.

The DeleteRequirements rule affects only the direct child requirements of the parent activity or requirement. If the business rule is not attached, the system executes the default behavior, which updates all direct child requirements and their subsequent child requirements to the Deleted status automatically.

In addition, requirements marked as Deleted can now be viewed and filtered within the user interface. All status changes related to requirement deletion are also recorded in the requirement history for audit and tracking purposes.

Activity Requirement Table Enhancement

Users can now sort data by any column within the Activity Requirement table, improving the ability to organize, navigate, and locate requirement information efficiently.

In addition, requirement statuses can be configured independently for the Policy, Client, Application, and Activity screens to display only the statuses relevant to each screen. This enhancement reduces clutter and helps users focus on applicable requirement statuses, improving usability and overall user experience.

Show or Hide for Inquiry Screen Result Tabs using ScreenMath Configuration

Added the ability to show or hide InquiryScreen Result tabs based on ScreenMath logic using the new SHOW attribute. This allows dynamic tab visibility driven by configuration, improving user experience and screen relevance. Existing configurations remain unaffected if the new feature is not used.

Restore Requirement Statuses on Activity Reversal for ProcessRequirements

OIPA now restores Requirement statuses when you reverse an Activity. If the Activity updates Policy or Client Requirements through the ProcessRequirements business rule, OIPA rolls back those Requirement status changes and returns each Requirement to its prior status.

Principal-First Repayment Option for Fixed Funds - Non Proportional Reduction

This release introduces a new plan-fund level configuration option for repayment processing in newly created Fixed funds - Non Proportional Reduction. Administrators can select between the existing proportional principal reduction method (default) and a new Principal-First non-proportional method for newly created fixed funds.

  • Non Proportional Reduction = Yes: The system reduces the principal directly by the repayment amount (floored at zero) without proportional (ratio-based) scaling.

  • Non Proportional Reduction = No: OIPA follows the default existing behavior.

Interest accrual and capitalization timing or process remain unchanged and continue to follow existing OIPA behavior.

Addition of attributes to INQUIRYSCREEN Business rule

OIPA now allows Inquiry results to refresh automatically when you change certain dropdown values by introducing SUBMITFORM and FIELD attributes, removing the need to repeatedly click the OK button. The system identifies which dropdown should trigger the update while keeping all existing screen behavior unchanged. This enhancement provides a faster and more efficient user experience.

History Logging for API-Driven Updates

This release enhances OIPA service APIs to support history by automatically writing history records for successful API-driven create/update operations (tagged with a new UpdateSource value of A for API vs M for manual/UI), ensuring API changes appear in the same entity history views as manual changes. Failed API attempts are not written to history; instead, they are captured separately (e.g., 400/401/403) in a new AsRestServiceErrors table with minimal/secured details (including encrypted request and masked IP) to support troubleshooting and accountability without retaining unnecessary personal data.

Enhanced Client Screen Context with Transaction Awareness

This enhancement enables the Client Screen to identify the transaction that triggers it by exposing the TransactionGUID in the screen context. The system uses this information to dynamically determine appropriate behavior, such as selecting the correct external system, displaying relevant fields, and pre-populating data based on the initiating transaction. This enhancement removes the need for custom workarounds and improves flexibility when integrating with external client management systems. When the Client Screen is accessed directly (outside a transaction):

  • No transaction context is applied.

  • The user manually selects client details as usual.

Improved Activity Processing Visibility for Cycle-Processed Activities

OIPA now displays more accurate Processed By information for activities processed by Cycle. When a spawned activity is processed by Batch Cycle, the activity shows Processed By: Cycle instead of appearing as if it was processed by the user who initiated the parent activity. This enhancement helps users more clearly identify whether an activity was processed by a user or by Cycle, improving activity history review and operational visibility across activity screens.